Subject: Trap for problem reporting

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Wed, 2 Aug 95 13:34:53 EDT

One question that's been around ever since the original work on
SNMP management for APPN was done has been what to do about problem
reporting:

  -  Sending SNA/MS generic Alerts is, and always has been, base function
     for APPN nodes, so it can be argued that there's no need to do
     anything about it in SNMP.

  -  The (rough) SNMP equivalent to the SNA/MS Alert, the trap, has never
     been portrayed as playing the role that an Alert plays:  reliable
     transfer of first-failure-data-capture data to the manager.  Rather,
     it has been seen as an unreliable mechanism for notifying a manager
     that it might find something interesting if it polled the agent.

  -  Nevertheless, there has been a desire to use SNMP to give an SNMP
     manager *some* indication that a problem has occurred in an APPN
     node that it is managing.

One approach, represented in /aiw/snasnmp/rfcalert.txt, was to encode
much of the content of an Alert (which, after all, an APPN node must
generate anyway) in a trap, and send this trap to the SNMP manager.  This
approach works, but it seems a little "heavy" for an APPN MIB we're
ultimately planning to submit to the IETF.

I have a second proposal for addressing problem reporting in our
standardized APPN MIB, once again starting from the premise that an
APPN node is generating SNA/MS Alerts anyway:  send in the trap only
the 32-bit Alert ID Number from the X'92' subvector.  With this proposal
we have

 -  one trap

 -  a small trap

 -  a means of reporting *every* problem the APPN node reports via an
    Alert:  APPN, APPC, lower layer, product-specific, whatever.
    Contrast this with the approach of defining separate traps
    for each of the 20 or so architected APPN Alerts--if we did this,
    we'd only be able to report these specific problems to an SNMP
    manager.

 -  something in the trap that uniquely identifies the nature of the
    problem being reported, which the trap receiver can use as a trigger
    for displaying specific information for that type of problem.
    (Remember NPDA's stored-screen Alerts from the early 80's?)

Obviously this mechanism doesn't duplicate all of the function of an
SNA/MS Alert:  there's no hierarchy, no detailed data qualifiers, no
Product Set ID, no text message, ....  But it might be a reasonable
compromise in terms of functionality, ease of implementation, and
acceptability to the larger SNMP community.

I'll attach a brief sketch of what this trap might look like, so
we'll have something specific to discuss at the AIW.

Bob

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
alertTrap NOTIFICATION-TYPE
   OBJECTS  { alertIdNumber }
   STATUS current
   DESCRIPTION
          "This trap carries a 32-bit SNA/MS Alert ID Number, as
          specified in SNA Formats."

   ::= { appnTraps 1 }

alertIdNumber OBJECT-TYPE
   SYNTAX OCTET STRING (SIZE(4))
   MAX-ACCESS read-only
   STATUS current
          "A 32-bit SNA/MS Alert ID Number, as specified in SNA Formats."

   ::= { appnObjects xx }